1. Field Of The Invention
The present invention is a system and method for obtaining resource information within an object located in a target functional process. More specifically, the present invention relates to a computer-based system and method for obtaining resource information within an object in a target functional process in a window server environment, where the names of the objects are not retained by the window server. It is contemplated that this resource information can be used for many purposes, especially for those relating to the testing of various versions of target functional processes in an object-oriented environment.
2. Related Art
The concept of dividing a display device into multiple "windows" (i.e., multiple regions each representing a separate functional process such as an application program or portion thereof) has become a popular user interface for computers. To facilitate control of these windows, "window servers" have been developed. These window servers manage the windows on a display device and perform such functions as redirecting input signals to the proper functional process represented by a window to which the input signals were initially directed. Thus, if a pointer device (such as a mouse) is used to "point" to a particular window on a display screen, then any input signals generated by the pointer device or keyboard will be re-directed by the window server to the application program (or portion thereof) that the window represents. An example of a widely used window server is the X Window System developed at the Massachusetts Institute of Technology of Cambridge, Mass.
The functional processes receive their input from a window server as a stream of input events. Input events can represent, for example, pointer device motion, keyboard key presses, pointer button releases, window size changes, etc, from an input device. However, the input events received by the functional processes are typically more than just redirected input signals. For example, the window server might receive the input signal from the input device, and from it determine the internal label that the window server has given to the window ("window ID") and the specific coordinates of the display device at which the "event action" of the input event is directed. This would then be the information sent to the functional processes. Thus, in this example, the window server would have to maintain the names of all of the windows of each functional process.
In order to properly direct input events to the various functional processes, typical window server environments use a concept of "ownership" of a window. Thus, each window is said to belong to some functional process, and any input event directed at a window is then accessible by the window's owner (via the window server).
Many window-oriented environments used with some window servers are "object-oriented." This means that entities such as functional processes (or portions thereof) are represented to the user as objects (often in the form of icons, menus, scrollbars, and text fields).
In a programming sense, an object is a combination of data and subroutines. A user can create the object and then need not service it since it will take care of itself (i.e, it has "methods" which instruct it what to do). For example, a "push button" object will contain all of the data and subroutines it needs to draw itself on the screen, know to ignore certain keystrokes directed at it, redraw its image when its window changes size, etc. Objects often contain a data field containing a name that the programmer gave to the object when it was created.
In some window-oriented environments the objects are divided into "widgets" and "gadgets." A widget is an object that has its own window (and thus its own window ID), and a gadget is an object that does not (i.e., there can be many gadgets in a single window). In such an environment a user may not know if an object shares a window with another object or if the object occupies the whole window (i.e., it is unclear whether an object is a widget or a gadget).
Since objects can typically contain other objects, the full name of an object comprises the name of the object itself (i.e., the name the programmer gave to it) plus the names of any higher-level objects (e.g., parent, grandparent, etc.) and the name of the functional process itself. In some window server environments, the window server can keep track of the name of each widget and gadget. However, some of the more recent window server environments such as those using "Motif" objects (developed by the Open Software Foundation of Cambridge, Mass) do not provide facilities for allowing the window server to store the name of the object. This makes it much more difficult to obtain object names, since the functional process itself must be analyzed to obtain this information.
In some window server environments such as those where the object names are not easily obtained, a data structure of objects representative of all the objects used in a functional process is stored within the functional process. Each object contains within it information or "resources" about that object. Such information can include the size and color the object should be if it is mapped (i.e., displayed) on a display screen, as well as other information such as its current window ID. This information can be of great use to entities outside the functional process (e.g., other functional processes), especially in a software testing environment. However, it is difficult to forward this information to other outside functional processes due to constraints of the window server environment.
Also, in some window server environments an "event description" is used to convey information outside the functional process about the input event directed to a particular object. This event description can be a subset of the information in the input event and/or can include additional information as well. In any case, the event description typically describes the "event action" which was directed to the object in the input event (e.g., a button was pressed).
Window servers such as the X Window System mentioned above often require functional processes using them to process many detailed events and to draw pictures and text using very low level functions. Libraries of higher level functions are available that make programming of the functional processes easier. One of these libraries for the X Window System is the X Window System Toolkit from the Massachusetts Institute of Technology. In addition to what is mentioned above, such libraries in the X Window System can also be used to determine the name of an object at which an input event is directed. However, in such a system if it is desired to pass the object name to an entity outside of the functional process, it is often the case that the object name is too large to be passed via an event description. Thus, some other mechanism would have to be used if the name of an object was desired by such an outside entity.
In today's software development environment, application programs are tested in some manner before being sold. Often testing is done by simply running the application program by hand. A logical extension of this is to run the application program (i.e., the functional process) by hand, and record both the input of the user (into a script) and the output generated by the functional process (which typically comprises data related to the output on a visual display device). Then, when subsequent versions of the functional process are developed (or run on different pieces of hardware) the information in the script can be automatically re-played and the resultant output can be compared with the previously recorded output. It should be noted that a previously recorded script can be used for purposes other than testing functional processes, such as for automated demonstrations.
When comparing previously recorded output to newly captured information, one can use the pixels generated by a display device as the basis for comparison. Thus, either all or a portion of the pixels of a display device can be captured and recorded in a script during the first execution of the functional process, and when the functional process is re-played the pixels of the display device are again captured and compared with those which were stored.
XTM is a tool developed by Hewlett-Packard Corporation of Palo Alto, CA that can generate and play back scripts for application programs utilizing the X-Server System, and which utilizes the pixel-capture technique described above.
Tools such as XTM are deficient for use in an object-oriented environment, however, in that everything is based upon coordinates. Thus, if the objects are repositioned by the window server or the display device is of a different resolution than the one used to record the script, then the recorded script will be of little use in playing back that which was recorded. To adequately determine whether one version of a functional process performs the same as a subsequent version in an object-oriented environment, however, one can compare the resources of an object (which would give an indication of what the output would look like in terms of the objects' internal representation of size, color, etc., but would not take into account the objects' absolute positions on a display screen) from one run of a functional process to the next.
Thus, what is needed is a system and method for obtaining the information of resources from an object in a window server environment where each functional process, rather than the window server, keeps track of object resources. This information can then be used for software testing purposes of many different types.